Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ien/ien-122

Text File | 1988-12-01 | 12KB | 296 lines

IEN-122                                Danny Cohen
                                        I  S  I
                            31 October 1979
                                        Halloween


                   On Addressing and Related Issues.
              (or: Fuel for a Discussion)
                   ---------------------------------


This note is about addressing of hosts on local nets.


THE AXIOM-A1

According to our current model a local net  (LN)  is  an  InterNetworkly
(like  "internationally")  known  network,  having an 8-bit Net-ID (NID)
assigned by the czar, registered in the official registry, etc., etc.

Furthermore, we have Axiom-A1 which states that:

          (A1): All Gateways know how to get to ALL Networks.

Here,  both "Gateway" and "Network" are spelled with capital letters  to
indicate  that  they  are part of the global InterNetwork Environment as
opposed to some trivial network or gateway, like the  hidden  ones,  for
example.

An interesting question is: "Is every local network a Network?".

Now the answer seems to be "yes".   I beg to differ.

I cannot escape the feeling that if we hold to  this  practice  we  will
soon  find that slow nets, like the ARPANET, cannot keep up with all the
inter-Gateways traffic needed for all Gateways to  know  all  about  all
Networks,  or  at  least about their existence and how to get there.  In
addition the storage capacity to keep this information and the cycles to
process  it  may  also exceed any reasonable estimate.  In addition, the
8-bit field may turn out to be too small for the NID.

This fear is based on the experience with  the  ARPANET  routing  update
which was frequent when the net was lightly loaded,  hence least needed,
and less frequent when it was needed the most,  when the net was heavily
loaded.

Also,  so far we have 31 NID's assigned (according to page 2 of IEN-117,
August 79) and this does not even include the 10 telephone lines each of
which has to be treated as a Network, according to Dave Clark; the 3 (at
least)  LN's  at  ISI,  at Lincoln, SRI, LLL, LBL, CMU and more.  In the
very near future every installation will have an  LN  (DECNETS  and  the
like) and probably so will any medium and big computer system.

                                  Page 2

If every PDP-10 (and bigger) computer has a  local  net  to  communicate
with its devices, file systems and the like, and if local nets have NIDs
then we may need LOTS of bits in LOTS of tables, and lots of  cycles  to
process  them,  if we ever manage to get enough bandwidth to communicate
them.

I propose the following:

    *  Let NID='377 be an escape-code, and NID=0 mean "this-Net".

    *  Let networks which have only one connection to the IN-environment
       (e.g., one Gateway only) be defined as Ln's.  Note, net, not Net.

    *  Let Ln-addresses be 24 bit wide.  The value 24 is used  here  for
       convenience only.  Obviously it may assume any other value, as is
       needed for any particular network.

    *  Let Ln's not have  NID's!!!  and  their  gateways  considered  as
       gateways (not Gateways); and

    *  Use source-routing to get to the hosts on these Ln's.

Hence, if there is a local net at site-X,  which  is  connected  to  the
IN-environment via IMP-Y on the ARPANET, then the addresses of processes
on this net should be:

         <NID=ARPANET> <IMP=Y> <HOST/LINK=Local-gateway>
         <NID='377> <the 24-bit address of that process>

Note that this is a 64-bit address !!

In comparison, now we have only 32-bit addresses, such as:

         <NID=X> <the 24-bit address of that process>

However,  for sites on Networks with only  16-bit addressing  (e.g., the
ARPANet and WBnet) it is  most advantegous to have local nets with 8-bit
addressing  only,  since  this allows packing of the entire address in a
single IP-address without the need for source-routing.

For example,  the IP-address of host-123   on  the  local-net  which  is
connected  to  the INE via the gateway which is on interface-3 of IMP-22
could be:

          <NID=ARPANet> <IMP=22> <HOST=3> <Ln=123>

The main idea is that if all the communication to X has to pass  through
"g"  then  there  is  absolutely  no point in propagating to the outside
world any information about the  structure  of  the  environment  inside
(i.e., "inwards" or "beyond") of "g".

                                  Page 3

If CMU, for example, has 5 local nets, all of which are connected to the
world  via  the  same IMP, then there is absolutely no point in treating
them as Networks with NID's, and polluting the  world  with  information
about  them, how to get to them etc., since the only way to get there is
to get first to the ARPANET and then to the CMU-IMP.

Proliferation of information which is not needed may be very costly,  in
storage, in cycles, and in bandwidth.

I don't believe that the fact that  someone  adds  a  local  network  in
Timbaktoo has to be propagated to all the Gateways.

In summary: Let's adopt the policy of  non-proliferation  of  NID's  and
let's use source routing.

THE THEOREMS T1, T2 and T3

The following three theorems have been proven experimentally and require
no more discussion:

         (T1): Any fixed size field will be found to be too small.

         (T2): Any fixed number of fields will be found to be too small.

         (T3): You can fool T1, or T2, but not both.

It is important to understand that T1 is not the only  reason  to  avoid
Networks  proliferation.   By having a very-very long NID field (say 100
bits) T1 may be fooled for some time.


THE POSTULATE-P1

Addressing hosts and processes which have several  physical  connections
with the INE (the InterNetwork Environment, or "Catenet") is a messy and
nasty problem.

This problem may be stated as:  "What is the  address  of  X  if  it  is
connected with the INE both as HOST-m on NET-i and as HOST-n on NET-j?".

If X is a network,  say NET-k,  then there are Gateways in between,  and
according  to  Axiom-A1 there  is  no problem in addressing it as NET-k,
since all the Gateways anywhere know how to get to it.

But if X is a host,  or any other  non-network  type  of  process,  then
there is a problem with its dual-homing (or better: multiple-homing).

If the choice between the multiple  addresses  is left  to  any  process
which  tries  to  communicate  with  X  then  we  have to admit that our
communication system is  not  capable  of  solving  ALL  the  addressing
issues,  and  push this problem "up" into hosts.  It goes without saying
that this does not mean that people (like senders of text messages) have
to remember these multiple addresses, and that programs and tables could
be used for it.

                                  Page 4

Here is where Postulate-P1 is defined.

          (P1): Every process should have only one IN-address.

This  is  possible  to  achieve  by  simply  defining  any  process,  or
collection of processes, as a Network.  For example, if hosts (which are
not Gateways) and local networks which have more than one connection  to
the  INE,  are  defined as Networks, with their own NID's, then Axiom-A1
guarantees that Postulate-P1 is always true.

Note how  nicely  this  alleviates  the  problem  of  handling  multiple
addressing,  source routing, the mess required to handle variable length
addresses, and more.

THE INNER STRUCTURE OF GATEWAYS

After establishing both Axiom-A1 and Postulate-P1 the  addressing  issue
is  totally  under  control.   There  may  be  a  slight difficulty with
handling the number of Networks which are required, but T1 can always be
fooled by assigning a very long field for the NID and by  assuming  that
the bandwidth, the storage and  the  cycles  are  avilable  at  all  the
Gateways to handle all the information about ALL these Networks.

Next, consider a process P which is  inside  the  Gateway  G(i,j)  which
connects NET-i with NET-j.  Such a process may deal with access control,
checks and balance, routing, or any of many other possible issues.

What is the address of this process?

G(i,j) is both HOST-m on NET-i and HOST-n on NET-j, just like X above.

Since our Postulate-P1 does not allow multiple homing, we cannot let the
address of this process be

            either  <NET=i><HOST=m><P>  or  <NET=j><HOST=m><P>

Hence, we must define the inside the Gateway to be another Network.

The new Network is obviously connected both to NET-i and to NET-j.   But
how?  Simply, as shown in <**> below:

          <**> Via  two  Gateways,  each  of  which is itself
               a Network with an InterNetworkly known NID.

               How is each of  these  Networks  connected  to
               its own neighboring Networks? Simply, as shown
               in <**> above.

Well, this does not seem to jibe perfectly with  the  notion  of  finite
length NID-fields...   By the way,  I suspect that you did not trace the
above explanation to its logical termination.  Did you?

There are several tacks one may take here to  mend  this  situation.   I
dare say that un-adopting Postulate-P1 is one of the better ones.

                                  Page 5

Let's do it, hence we accept  that  the  multiple-homing  issue  is  not
necessarily always solved completely by the Gateways.

There is a lot to be said about multiple-addressing but this is left for
yet another note.

Once this heresy is introduced -- even Local Networks with more than one
connection to INE may be treated as Ln's without NID's !!


CONCLUSION

Local networks, regardless of the number of connections which they  have
to the INE, should NOT be treated as Networks with NID's.

AFTERTHOUGHTS

The network forefathers demonstrated remarkable foresight by  allocating
an  8-bit  field  for  HOSTs  on  the ARPANet.  The notions of that many
hosts, that many IMPs and several computers connected to a single IMP at
one location were ahead of their time.

Since then the scenario developed in several directions.  First,  it  is
not  THE network any more.  Many networks, of different technologies are
in existence.  Second, on many occasions there is more than one computer
at the same location.

The concept of HOST is gradually and  implicitly  replaced  by  the  new
concept of SITE.  Here "site" is some combination of an organization and
a certain location, like "ISI", "MIT" or "BBN", but not  like  "DoD"  or
"Cambridge".

The association of processes, people, files, devices is not per-host, as
it  used to be, but more and more per-site.  This is especially apparent
when text messages ("mail") are discussed.  It is typically expressed by
statements  like:  "I  know that he is at MIT, but have no idea on which
machine there, and don't even care to know!".

I suspect  (but  am  not  quite  sure)  that  the  similarities  between
local-networking  and  Networking  (a  la ARPANet, WBCNet and PRNet) are
deeper than just a lucky coincidence, but less than a  deep  fundamental
phenomena.

Treating local networks with all the "glory" which  is  associated  with
"real"  (or  "global")  networks -- may be misleading and may cause more
artifacts than what we bargain for.

                    Let's think about it......

                                  Page 6

A COMMENT ABOUT MULTIPLE-ADDRESSING.

Without suggesting anything to the INE,  following are some examples  of
the handling of multiple-addressing in Telephonia.

My addresses, at ISI,  are 1-213-822-1511 thru 1-213-822-1519 (plus some
non-contigious numbers).   However,  no one  outside  of ISI has to know
these numbers, since all the communication which is addressed to the one
of them is automatically re-routed to the rest, if so needed.

I have one address at ISI, and another at home.   The re-routing between
them  takes  place  outside the "pure" communication system,  unless its
definition is augmented to include the human operators, secretaries, and
the like.

If I am not around  someone probably can provide the sought information.
This multi-address (of the information!) is the choice  of  whom-to-ask.
It is very difficult to stretch the definition of  communication  sytems
to include that.

These examples show that in Telephonia  the multiple-addressing issue is
handled at several levels. Maybe the same is true for internetting, too.